Television programming was originally broadcast to viewer's television sets through a radio wave transmission in a defined frequency band referred to as a channel. Different people in different places could receive the same broadcast signal by tuning in to the same channel.
As technology progressed, these broadcast signals were retransmitted over a common access cable infrastructure. These scenarios are illustrated in FIGS. 1a and 1b. In FIG. 1a, broadcast tower 100 transmits a program to televisions 102 through radio waves over channel 104. Other towers, not shown, can transmit other programs over different channels. In some setups, different transmitters use the same physical tower but transmit on different channels. In FIG. 1b, tower 100 still transmits to television 102 over channel 104, but can also have its programming carried by cable infrastructure 106 to television 102b. 
As technology has provided new, or improved, delivery mechanisms they have been employed to allow for improved or enhanced television experiences. With the arrival of packet based data networks, and the processing power to properly encode and decode video data at sufficiently high frame rates, Internet Protocol TV (IPTV) is making inroads. IPTV employs a packed based delivery network where infrastructure elements are employed to verify that a given use is authorized to access content before the requested content is delivered to the user.
In packet based networks, broadcasting data is not typically done. Instead data is either sent to a specific node (unicast) or sent to a plurality of nodes (multicast). Many users can join a multicast session, and from the user perspective, this may not show any differences from a conventional broadcast.
In many conventional IPTV environments, the network is built upon an Internet Multimedia subsystem (IMS) based network employing Session Initiation Protocol (SIP) as a control channel protocol. SIP commands are employed to provide control over the initiation and termination of other sessions. One benefit of SIP is that a node in the network can initiate a session between two other nodes without needing to participate in the resulting session.
Typically, the SIP session is used to create a Real Time Streaming Protocol (RTSP) session which in turn is used to create a delivery channel, typically using a protocol such as the Real-time Transport Protocol (RTP) between a content source and the Open IPTV Terminal Function (OITF) which is often provided in the form of a set top box (STB). The RTSP session is used to provide the user with playback controls for the content delivered in another channel, called the delivery channel. The packets containing the actual video content are not delivered through the RTSP session, but instead are delivered in the delivery channel using another protocol such as the Real-time Transport Protocol (RTP) or other protocols determined to be appropriate to the particular implementation.
Thus, the content is delivered as packets using a protocol such as RTP in a session controlled by RTSP. Such a setup is shown in FIG. 2, where an OITF 110 and a Content Delivery Function (CDF) 114 have an RTSP Session 118. This RTSP session 118 is established indirectly through the SIP session 116 established between OITF 110 and IPTV CS 112. SIP session 116 is used to invoke and tear down RTSP session 118, as well as to perform other session management functions. RTSP session 118 is used to invoke and tear down RTP session 120 as well as to perform media control actions relevant to the content delivered through RTP session 120.
The content is delivered to OITF 110 through RTP session 120. As described above, the user can issue, from OITF 110, RTSP commands such as PAUSE, PLAY, and RECORD in RTSP session 118.
A variety of enhancements to distribution of content have been enabled through IPTV. One such enhancement is the ability of a user to perform session replication. A user can replicate a session through a series of SIP commands that will be well understood by those skilled in the art. This allows a user to create a second set of sessions between the CDF and a second OITF (typically through SIP commands involving the IPTV CS). This replication creates a second set of session independent of the first set. Often the replication is performed using SIP commands that may also involve causing the first OITF to issue RTSP commands (e.g. PAUSE) at the start of the replication procedure, and causing both OITFs to issue RTSP commands (e.g. PLAY) at the completion of the replication operation.
One of the results of the evolution of television content delivery being aimed at ensuring that viewers have a consistent experience, is that many of the manners in which viewers interact with each other and the experience of watching television has remained relatively constant. Content is still consumed in isolation or with a group of people who are gathered in a single location. A viewer, with access to a controller, can guide or control the viewing experience of the gathered group through the ability to pause a session, to rewind a session, or otherwise control the playback of the content. This sort of experience has allowed and encouraged groups of people to gather to watch sporting events and other programming that may be considered to be cultural touchstones such as the finale to a popular television show.
With the growth of social media, viewers have taken to attempting a communal viewing experience with people that they are not closely located to by using social media messaging to share comments about a program. This clearly demonstrates the desire of many users to explore and experience the social aspects of the television viewing experience without concern about the geographic co-location of the individuals.
Therefore, it would be desirable to provide a system and method that obviate or mitigate the above described problems.